PROPOSTA MINIMA Cambia il contratto purchase inserendo, durante il deploy, un ammontare minimo di wei che il buyer deve offrire per fare la proposta. CAMBIA VENDITORE Modifica il contratto purchase per dare al seller la possibilità di passare il contratto ad un altro seller in qualunque momento, cioè cambiare la variabile seller. CAMBIA SPEDIZIONERE Può succedere che il buyer e il seller non siano soddisfatti dello shipper. Modifica il contratto purchase per dare la possibilità a loro, se sono d'accordo, di cambiare lo shipper. Suggerimento per la strategia: ci sono parecchie strategie, questa è quella che mi pare la più veloce. Costruisci una funzioni che possa essere chiamata solo da buyer o seller dove l'utente può proporre un nuovio indirizzo per lo shipper. Se l'utente è il seller, scrivi l'indirizzo in una variabile new_shipper_byseller; se l'utente è il buyer, nella variabile new_shipper_bybuyer. Se queste due variabili contengono lo stesso indirizzo (il che vuol dire che la funzione è stata chiamata prima da uno e poi dall'altro), allora aggiorna la variabile shipper. RIMBORSO PARZIALE Il seller vuole dare la possibilità al buyer di cambiare idea. Questo deve essere fatto dopo che l'acquisto è stato accettato, ma ovviamente prima che sia stato consegnato o non consegnato. Durante il deploy, il seller stabilisce una percentuale e il buyer nello status Shipped può chiamare una funzione reject_purchase e ottenere solo la percentuale di soldi indietro, mentre il resto va al seller. Stai attento che Soliditi non ha float e pertanto la tua percentuale deve essere un numero intero. Stai anche attendo alle divisioni. TANTI ACQUISTI ASSIEME OPZIONALE E DIFFICILE Vogliamo rendere possibile gestire tanti acquisti allo stesso tempo. Però teniamo comunque la limitazione che un buyer può fare solo un acquisto (gli altri sono fatti da altri buyer). - Innanzitutto abbaimo bisogno di una struttura dati per memorizzare l'indirizzo di ogni buyer e sui soldi che ha pagato. Questa è una struttura identica ai balances della banca. Abbiamo bisogno di una struttura simile per memorizzare lo status di ogni acquisto di ogni buyer e un'altra per il proposalTime. - Adesso il concetto di buyer non esiste più, perché chiunque può essere un buyer. Quindi, ogni volta che vogliamo informazioni sullo status o sul tempo, dobbiamo guadare alla struttura dati associata a chi sta facendo la chiamata alla funzione. - Ogni volta che il seller o shipper fanno qualcosa, devono indicare chiaramente PER QUALE BUYER stanno agendo. - Ovviamente non devi mandare in giro tutti i soldi del contratto, ma solo i soldi indicati nel balance di ogni buyer. MINIMUM PROPOSAL Modify purchase contract to decide, during deployment, a minimum amount of wei. The buyer must offer at least this amount to be able to make the proposal. CHANGE SELLER Modify purchase contract to give the seller the possibility to pass the contract to another seller at any time, i.e. change variable seller. CHANGE SHIPPER It might happen that both the buyer and the seller are not satisfied with the shipper. Modify contract purchase to give the possibility to them in agreement to change the shipper. Strategy suggestion: there are several strategies, this is only a possibility which seems the fastest one. Strategy easy: build three functions, in the first one the seller proposes a new shipper and puts its address in a variable, in the second one the buyer proposes a new shipper and puts its address in another variable, the third one checks whether the two proposed shippers are the same and in case changes the shipper variable. Straegy less easy: Build a function which can be called only by buyer and seller where the user can propose a new shipper's address. If the user is the seller, write the proposed address into variable new_shipper_byseller; if the user is the buyer, into variable new_shipper_bybuyer. If these two variables are the same (which means that this function has been called by the seller and by the buyer), update variable shipper. PARTIAL REFUNDING The seller wants to give the buyer the possibility to change his mind. This must be done after the purchase has been shipped but obviosuly before being delivered or not_delivered. During deployment the seller sets a percentage and the buyer in Shipped status can reject_purchase and get only that percentage of his money back and send the rest to the seller. Beware that Solidity does not have float, thus arrange your percentage as an integer number and then pay attention to divisions. SEVERAL PURCHASES OPTIONAL AND CHALLANGING We want now to make it possible to deal with several purchases at the same time. However, we still keep the limitation that one buyer can make only one purchase at the time (the pother purchases are done by other buyers). - We need first of all a data structure to store the address of each buyer and paid money. This is done with a mapping structure, identical to the bank's balances. We also need a similar data structure to store for each buyer the status of his purchase (remember that it is automatically set equal for all addresses to 0, i.e. Status.Start). And another one for the proposalTime. - Now the concept of buyer does not exist anymore, because anybody can be a buyer and at any status. Therefore, when dealing status or proposalTime, we must modify/look at the variables inside these data structures and not at the original status or proposalTime. - Whenever the seller or shipper acts (accept and ship, reject, delivered, not_delivered), they now must clearly indicate FOR WHICH BUYER they are acting. - You have obviously not to send around all the contract's money, but only the money indicated in the balances for that buyer.